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The invention relates to the field of electronics and data processing, and 
particularly to methods and apparatus for distributed cryptography incorporating shared 
randomness. 

BACKGROUND 

Distributed cryptography deals with cryptographic services which are distributed 
amongst parties so that a plurality of the parties have to take action to perform an act. For 
example, a cryptographic function may be re-represented as distributed pieces. When 
given an input, the parties holding the pieces have to come up with a quorum of 
themselves, and each member of the quorum activates its piece over the input, resulting in 
a partial result for each member of the quorum. The partial results are combined into a 
final result that correctly represents a cryptographic function such as decryption, 
signature, or any other function. More particularly, the function may be based, for 
example, on discrete logarithm over a prime field or other domain or functions based on 
hardness of factoring. 

A shared cryptographic function provides a service which has built-in distributed 
trust. In distributed trust services using shared cryptographic functions, the service 
operation is typically presented as a single coherent element which is managed centrally 
to achieve a uniquely identified sensitive function. The service has decentralized control 
for security against insiders and for geographic and/or organizational trust distribution. 
Shared cryptographic functions support cryptographic services such as certification 
authority and key escrow. Requirements of state-of-the-art technology impose stronger 
security and operational constraints than those present in existing systems. These 
constraints have forced integration of various technological components, thus introducing 
more complicated workflow relationships. These workflow relationships tend to be more 
complicated than input-output relationships and may require more than just careful 
access-control mechanisms. 

In high-end secure systems which are not isolated, one cannot rely solely on 
software modules, operating systems, and physical security. Secure hardware tokens are 
often included in high-end secure systems to enhance security protection. Alternatively, 
cryptographic modules, e.g., co-processors, may be added as well as other cryptographic 
facilities, e,g., hardware or software. Hardware tokens are hosted imder the software of 




the general purpose computing units. Thus, hardware units do not communicate with 
each other directly. The hardware tokens are the "most protected" system components, 
and thus the most trusted elements of high-end secure systems. To assure "end-to-end" 
security at the highest level, the hardware tokens should provide security themselves. 
5 Such explicit security seems to require an explicit "hand-shake" among the components, 
/.e., the hardware tokens. Such explicit "hand-shake," however, overburdens the 
workflow by adding interactions, reduces performance, and adds to the required 
functionality by requiring mutual multi-party authentication of the limited computing 
environment at the hardware tokens. 
10 The following references provide additional background of the invention and are 
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[A] R. J. Anderson, Why Cryptosystems Fail, Proceedings of the First Annual 

ACM Conference on Computer and Communications Security, CCS '93. 

15 [B] R. Blakley, Safeguarding Cryptographic Keys, FIPS Con. Proc (v. 48), 

1979, pp. 313-317. 

[BF97] D. Boneh and M. Franklin, Efficient Generation of Shared RSA Keys, 

Crypto 97 proceedings. 

20 

[BDL] D. Boneh, R. DeMilo and R. Lipton, On the Importance of Checking 

Cryptographic Protocols for Faults, Eurocrypt 97. 

[B88] C. Boyd, Digital Multisignatures, IMA Conference on Cryptography and 

25 Coding, Claredon Press, 241-246, (Eds. H. Baker and F. Piper), 1989. 

[BGS] J. Bull, L. Gong and K. SoUins, Towards Security in an Open Systems 

Federation, Esorics 92. 

30 [DDFY] A. De Santis, Y. Desmedt, Y. Frankel, and M. Yung, How to Share a 
Function Securely, ACM STOC '94, pp. 522-533. 

[DF89] Y. Desmedt and Y. Frankel, Threshold cryptosystems, Advances in 

Cryptology-Crypto '97, pp. 307-315. Springer- Verlag. 

35 

[DF91] Y. Desmedt and Y. Frankel, Shared Generation of Authenticators and 

Signatures, Advances in Cryptology-Crypto '91, pp. 457-469. Springer- Verlag. 

[DH] W. Diffie and M. Hellman, New Directions in Cryptography, IEEE Trans. 

40 on Information Theory 22(6), 1976, pp. 644-654. 

[FIPS 140] FIPS 140-1 , Security requirements for cryptographic modules. National 
Institute of Standards and Technology, January 1, 1994. (See also 
http://csrc.nist.gov/fips/) 



- 2 - 



10 



[F89] Y. Frankel, A practical protocol for large group oriented networks, In J. J. 

Quisquater and J. Vandewalle, editor. Advances in Cryptology, Proc, ofEurocrypt '89, 
(Lecture Notes in Computer Science 773), Springer-Verlag, pp. 56-61. 

[FGMY] Y. Frankel, P. Gemmel, P. Mackenzie and M. Yung. Proactive USA, 
crypto 97. 

[FGMY2] Y. Frankel, P. Gemmel, P. MacKenzie and M. Yung. Optimal Resilient 
Proactive Public-Key Systems, FOGS 97. 

[FGY] Y. Frankel, P. Gemmel and M. Yung, Witness Based Cryptographic 

Program Checking and Robust Function Sharing. STOC96, pp.499-508. 

[FMY] Y. Frankel, P. MacKenzie and M. Yung. Robust Distributed Efficient 

15 RSA-key Generation, manuscript. 

[GJKR] R. Gennaro, S. Jarecki, H. Krawczyk, T. Rabin, Robust Threshold RSA, 

Crypto96, pp. 157-172. 

20 [GGM] O. Goldreich, S. Goldwasser and S. Micali, How to construct random 

functions, J. Comm. Sci. 28 (1984), pp. 270-299. 

[HJJKY] A. Herzberg, M. Jakobsson, S. Jarecki, H. Krawczyk, M. Yung, Proactive 
Public-Key and Signature Schemes Proceedings of the Fourth Annual ACM Conference 
25 on Computer and Communications Security, CCS '97. 

[J A] M. Joseph, and A. Avizienis, A Fault-Tolerance Approach to Computer 

Viruses, IEEE Sym. on Security and Privacy, 1988, pp. 52-58. 

30 [K] R. Kocker, Timing Attacks on Implementations of Diffie-Hellman, RSA, 

DSA and Other Systems, Crypto96. 

[M] S. M. Matyas, Key processing with control vectors, Joumal of Cryptology, 

3(2), pp. 113-136, 1991. 

35 

[MT93] R. Molva and E. Tsudik, Authentication Methods with Impersonal Token 

Cards, IEEE Sym. on Security and Privacy, 1993, pp.56-65. 

[OY] R. Ostrovsky and M. Yung, How to withstand mobile virus attacks, Proc. 

40 of the 10^ ACM Symposium on the Principles of Distributed Computing, 1991, pp.5 1-61. 

[RFLW] M. Reiter, M. K. Franklin, J.B. Lacy and R. N. Wright, The Q Key 
Management Service Proceedings of the Third Annual ACM Conference on Computer 
and Communications Security, CCS '97. 

45 

[RSA] R. Rivest, A. Shamir and L. Adleman, A Method for Obtaining Digital 

Signature and Public Key Crypt osy stems, Comm. of ACM, 21 (1978), pp. 120-126, 

[Sh] A Shamir, How to share a secret. Comm. of ACM, 22 (1979), pp. 612- 

50 613. 



- 3 - 




[R] T. Rabin, A simplified approach to Threshold and Proactive RSA^ 

Proceedings of Crypto 98, Spriner-Verlag, 1998, pp. 89-104. 

5 [Y94] B. Yee, Using Secure Coprocessors, Ph.D. thesis, Carnegie Mellon 

University, Computer Science Tech. Report CMU-CS-94-149, May 1994. 

SUMMARY 

The present invention develops cryptographic mechanisms for high consequence 
security systems employing shared randomness between the operating parties. Using 

10 shared randomness and incorporating randomness into a distributed cryptographic 

operation allows end-to-end security by non-commimicating hardware components within 
the high-end secure system. Shared randomness may be accomplished by sharing a 
cryptographic key stored in secure hardware tokens hosted by potentially less secure 
software and/or general purpose computing units, that perform a distributed cryptography 

15 (e.g.^ distributed RSA signing service). The shared randomness is integrated into the 

computation of the partial results in a distributed cryptography system. The integration of 
the shared randomness into the partial results achieves a hand-shake amongst the tokens. 
Namely, when the operation is successful, a result is computed with assurance that the 
right parties have participated in the computation. This assures binding of the operating 

20 parties, and overall the added shared randomness is added security to the system. Work 
load is balanced between the token and its host. 

In a preferred embodiment of the invention a method of distributed use of 
cryptographic keys between a plurality of distributed electronic devices is developed in 
which the distributed electronic devices are capable of communication with a central 

25 server to develop a cryptographic output using shared random values. The method 

comprises the steps of: (a) computing shared values over a known and agreed context; 
(b) generating random values using the shared values; (c) generating a partial result for 
each device using the random values; and (d) computing an output based on the partial 
result. 

30 BRIEF DESCRIPTION OF THE DRAWING 

The present invention will be described below with reference to the attached 
drawing in which: 

FIG. 1 is a block diagram illustrating horizontal separation of distributed 
cryptographic service architecture. 

35 
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BRIEF DESCRIPTION OF THE PREFERRED EMBODIMENTS 

To achieve trust among hardware components, an expHcit "end-to-end" 
hardware-to-hardware interaction, not relying on non-hardware components, may be 
used. Handshakes and mutual reliance may help in distributed systems to provide mutual 
verifications that increase system integrity, availability, and security [A, BGS]. When the 
hardware components are not directly connected, such handshakes cannot be performed 
directly. An implicit indirect verification of hardware imits which complies with the 
vertical and horizontal separations of the architecture that is not resource consuming is 
needed. 

An "implicit indirect hand-shake" via servers and the software units that connect 
them is possible using a new primitive. Operation using the new primitive will assure 
high-level "end-to-end" trust while maintaining the vertical layers. New secure 
algorithms and protocols achieve mutual multi-party trust at the management level. End- 
to-end security using the new primitive does not require the secure hardware token and 
can provide end-to-end security at the divisional units. 

In general a high-end security system may be built with increased computational 
requirements. Hardware and software units may be added with relatively marginal added 
cost. The use of hardware is not so obvious when there are efficiency concerns because 
secure hardware is typically slow, /e., hardware tokens are often times an "old 
generation" computing device by the time they are certified. In addition, not all hardware 
devices have accelerator chips to perform sufficiently large computation (2048 bit RSA 
accelerator chips are not prevalent today). Security may be reduced by lowering the 
security parameter, e,g.^ using a small composite RSA. A reduced security parameter is 
unacceptable because adversaries generally have the state-of-the-art equipment. 
Therefore, there is a need in which to balance security protection with performance. A 
trade-off between hardware performing some of the computing and the software unit of 
the computational device (e.g., a PC) performing the rest is needed. In general, for high- 
end security, additional computation should be tolerated (since the budget allows for 
additional computational devices to be added). This additional computation should not be 
perfomied at the costly secure hardware token layer. The methodology disclosed herein 
balances computational efficiency concems. 

Shared randomness is achieved between two or more entities by sharing a 
common key and applying a pseudorandom function or a pseudorandom number 
generator to generate a value that is common among the entities. Methods for sharing 



• 



keys, pseudorandom functions, and pseudorandom number generators are procedures and 
notions which are known to those skilled in the art. By way of example, shared 
randomness methodology is applied to cryptographic calculations using the RSA 
algorithm. The RSA key generator produces two large random primes p\ and and 
5 computes composite n=p\ p2 and the Euler toitent function ^{ri) — (p\~ l)(p2 — !)• To 
determine the secret key, the generator chooses a random number d such that gcd(J, <[)(«)) 
= 1 . The public key is n and e such that ed ^ I (mod (()(«)). The one-way (hard) direction 
of RSA (used in decryption or signature of a message m) is Sm = w^(mod w), whereas the 
public (easy) direction (used in encryptions and verification of signature) is (Smf (mod n) 
10 which returns /w. 

The RSA function is a building block for many secure systems where the 
adversary is allowed to initially access the system and get results based on various 
O restrictions on the input, /. e. , chosen plaintext encryption, random plaintext to be signed, 

^2 15 Two types of separations of system elements are distinguished: Horizontal and 

m Vertical. 

' ? Horizontal modules divide the architecture into divisional units with separate 

^ "trust domains." The domains are derived from the organizational structure, which can 

Q be defined by business structure, contracts, geography, security policy, etc. 

' ^ 20 This structure defines the upper level layer that enforces organizational policy (trust 

relationships) and preferably fits within existing management workflow. 

Vertical components divide the architecture into layers of technology boimdaries: 
network interfaces, network firewalls and access control gates, operating systems, 
application software, £irid hardware tokens (as an example of trusted device). Other 
25 components such as humans (authorization of operators), physical secvirity, and auxiliary 
and administration systems such as logging, tracing, secure synchronization, and recovery 
may be added. A further discussion in the context of the Q software key management 
system can be found at [RFLW]. 

Combining the horizontal and vertical components into a working architecture 
30 involves two basic design aspects ~ separations and bindings. Separations divide 

horizontally into divisional (organizational) modules and vertically into components in a 
divisional module. Bindings assure smooth collaboration among authorized elements 
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only, both horizontally and vertically. The binding method disclosed minimizes security 
exposure and maintains the integrity of the cryptographic service. 

FIG. 1 is an example of the horizontal module's workflow. A cryptographic 
service requester 104 is one or more entities which issues requests to the centralized 
management (defined by, for example, the organizational structure) asking for 
cryptographic service. The request is first sent to the server 108. This request, for 
instance, can be for issuing the organization's signature on a specified message or 
decryption of wiretapped cipertext. To protect against various attacks (e.g., man-in-the- 
middle), the cryptographic service requests are authenticated, usually with the requester's 
signature or otherwise. This is analogous to an upwards request in a mandatory integrity 
policy model. The server 108 forwards, over an authenticated channel 112, the request to 
the divisional units 110 and may also first negotiate which divisional imits will participate 
in performing the cryptographic service (assuring availability and/or managing load 
balancing at the divisional unit level). After verifying the validity of the cryptographic 
service request and based on their specified security policy, the divisional units 110 
perform a computation based on the information in the cryptographic service request and 
private information. The divisional units 110 then forward the output over an 
authenticated chaimel 1 12 to the server 108. When all the necessary divisional units 
resporid, the server 1 08 is able to complete the requested cryptographic service. Then, the 
server 108 will grant the result to the requester 104, either in plain form or, if security is 
required, e.g., a decryption service, encrypted under the requester's key. 

The divisional units 110 have a built-in redundancy when the number of divisional 
units required to perform the service is smaller than the total number of divisional units. 
Servers and cryptographic service requesters may be added to the system if high 
availability is required. Various maintenance procedures may be executed internally in 
the system, e.g., a secure time synchronization. 

The horizontal units in the present example jointly perform RSA signing. Such 
distributed signing has been shown possible algorithmically (at some level of distribution 
or another) [B88, F89, DF91, DDFY, FGY, GJKR, FGMY, FGMY2]. An organization 
(centralized management), which is externally one entity, possesses an RSA signing 
public key, PK. The cryptographic objective of a distributed RSA fimction sharing 
system is to distribute the RSA signing capability so that any / or more units 
corresponding to divisional units can sign a message that is verifiable by PK, yet an 
adversary, with at most t-~l divisional units, cannot sign. This is the same protection as 



in secret sharing [Bl, Sh], but in this example, the signing operation may be repeated as 
long as the key is valid. Analogous to the non-digital methods, the security policy and the 
intemal organization signature approval structure should often be transparent to extemal 
entities. Transparency serves three purposes: (1) extemal parties prefer not be 
5 encumbered by and, generally cannot enforce, the signing party's policy and practices; (2) 
transparency ensures that extemal entities maintain compatibility independent of the 
intemal structure and changes in intemal stmcture; and (3) since extemal entities do not 
know who or how many individuals "approved," /.e., participated in, the signing of the 
message, intemal organization secrecy is maintained, which is very important for certain 

10 organizations. The Basic IBM security modules and the RSA Certificate Issuing System 
(CIS) assume multiple agents control physical keys in order to operate the cryptographic 
unit. The physical keys hold electronic keys and other information and must be inserted 
into the device. In contrast, the present system employs distribution of tmst among 
remote components that are hidden inside different vertical components and do not 

15 interact explicitly. 

Secure hardware tokens provide some additional protection. In fact, current 
practices (for instance in banking and military applications) dictate the use of secure 
hardware mechanisms to enhance security protection. If hardware tokens do not have 
their own protected I/O between user and hardware token, and most do not, they caimot 

20 protect against operating system and application layer attacks in which "illegal" 

(unauthorized) inputs are submitted to the device. They, however, can protect the long- 
term private keys. Through the use of auditing, monitoring, vims detection, intrusion 
detection, proactive security [OY, HJJKY], etc., an attacker on software system that is 
well maintained may have only a short-term affect, which is acceptable in some 

25 scenarios. 

Folding or incorporating the shared randomness based on shared keys into the 
computation modifies the original computation by further randomizing it. By 
incorporating shared randomness into the computation, bindings are created. The 
presence of components in the computation is assured without further checking. Shared 
30 random keys are typically used for encryption or authentication, but here they are used as 
computation-modifiers. Since they are shared, the modification at some location can be 
accounted for at another location or via computations done at that other location. 
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Hardware-Based Secure Distributed RSA Incorporating Shared Randomness 
A first embodiment of the present invention incorporates shared randomness into 
a hardware-based secure distributed RSA system. Secure distributed RSA is optimized 
by using shared random key computation and achieves security in operation as long as no 
5 quorum of the divisional units is compromised. The elements signed by the software are 
allowed to grow relative to the size of the public key block (/ is the number of imits, 
L = l\, t-out-of / are needed to produce a signature). In the example below there is no 
distinction between hardware and software. The protocols described are useful when 
hardware tokens are not incorporated into the architecture. 
10 Let PRF)t( ) denote a pseudorandom fimction indexed by the key k. 

Pseudorandom functions are used here by way of example, but other shared key functions 
may be used. 

Setup: The following one time setup is performed for shared values k. 

• Generate an RSA function having a public key (e,n) and a private key d. 
15 • Due to the extended Euclidean algorithm, the dealer can compute P, 

s ' such that 1 = eP-^ — ' where H= gcd(e,Z). The dealer chooses a random 

polynomial ^(x) = Ao + A ix+ • • • +At.jx^'\ such that ^(0) =Ao=^L^ 'k^ and Aj 
e r{0,Z, ■ • • ^llff'^^t) for 1 < j < / - 1 (the polynomial is over a subset of the 
integer numbers: Z). 

20 • Entity / with public interpolation point x, = / receives secret shadow si = 

A{xi) G Z and the Server receives public point P. 

• Each pair of entities {ij) jointly generate a shared secret key for 
generating shared randomness a ij — a jj for the pseudorandom generator. 
This can be performed via Diffie-Hellman key exchange [DH] (v^th added 

25 authentication) or some other shared randomness generation technique. 

The above key generation and share distribution is based on co-pending patent 
application no. 08/842,080, filed April 28, 1997, titled Optimal Resilience, Proactive, 
Public-Key Cryptographic System and Method ("Optimal Resilience")? v^hich is hereby 
incorporated by reference in its entirety. Using [BF97] and co-pending patent application 

30 no. 09/3 1 5,979, filed May 21,1 999, titled Robust Efficient Distributed RS A-Key 

Generation, which is hereby incorporated by reference in its entirety, one can employ a 
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distributed dealer procedure among the hardware devices to produce a distributed trust of 
this sharing; hence not relying on any single entity. 

Operational Phase: Let A where | A| = / be the divisional units designated to participant 
in the signing (they are available to the system's management at this point). The 
management Server notifies the members of A what A is. Signing is used as an 
example of incorporating shared randomness computation, but shared randomness 
may be used with other cryptographic functions (e.g.^ decryption). 

• Entity y computes s ' mj,K = * ^y, a + { Z ve A\{j}signO* - v)- PRF^^.^ (w)} where 

• Entity j transmits Smj^A = m^'"'^'^ mod n and transmits the result to the 
Combining Server. 

• The Combining Server computes signature of m, Sm = m^ • 0^^^ 5'm,v,Aniod n. 

• The Combining Server may "validate implicit hand-shake" and checks that: 

7 

{Smf =m{modn). 

The above protocol produces a secure and correct signature of a message m 
corresponding to public key {e,ri). The sharing of the pseudorandom functions among the 
hardware units and their invocation in the computation generates a 'V-wise hand shake" 
among the hardware components This creates a self-awareness property where the 
absence of a unit is detected as long as a single original unit is present. The distribution 
of the computed exponent into hardware exponent and software exponent has achieved 
the balancing between hardware and software as discussed below. Moreover, the sharing 
of the pseudorandom functions allow the protocol to be non-interactive, where the 
previous practical scheme of this nature required initial interaction to exchange true 
random bits. 

A balancing between efficiency and adversarial setting (attacks) is provided by 
incorporating shared randomness. Software compromise and hardware compromise are 
distinguished using shared randomness. 

Another embodiment of the present invention provides a scenario against an 
adversary which attacks a single device, the device is protected against timing attacks 
(due to exponentiation time channel being a pseudorandom function dependent but 
exponent independent), as well as attacks by an adversary performing I/O queries into a 
single device. 




A modification of the operational phase allows for distinguishing between 
hardware and software at a divisional unit. 

Operational Phase: Let A where | a( = / be the divisional units designated to participant 
in the signing. The divisional units are available to the system's management at 
5 this point). The management Server notifies the members of A what A is. Signing 

is used as an example of incorporating shared randomness computation, but 
shared randomness may be used with other cryptographic functions (e.g,, 
decryption). 

• Entity^ computes s ' ^j^a = Sj ■ Zy^ + { Z v g A\{/}sign(/ - v) • PRF^ . ^ (m) } 
10 where z,;^ = Yl .^^^y^i^j " ^v)"kO - ^v). 

• Entity j hardware provides to its software S' ^ ^.^ = w^'"'^'^ , r mod n where r 

^ f may be (pseudo) random bit string of length poly(log(rt)) or zero (0). Use of 

r p zero may be preferred depending on hardware constraints. 

'2 • Entity j now transmits Sm,j,A = m^'^^^ , w'^ mod n based on the input it 

l y 15 received from the hardware and transmits the result to the Combining Server. 

• The Combining Server computes signature of Sm=m^ • 11 veA ^m,^,K mod n, 
^i,^^ • The Server may "validate implicit hand-shake" and checks that: {Smf 

ly ? 

,n ^/w(mod«). 

If an adversary has access to / or more of the computing devices, the adversary 
20 can sign any message, since it can authorize the signature request to the hardware tokens. 
It is assumed that hardware tokens only have I/O interfaces through software controlled 
devices. A signature interface between the Server/requester and the hardware tokens may 
be included to avoid unauthorized requests by the local or divisional xmit. This protocol 
assumes both hardware and software have to be compromised at many locations, which is 
25 an improvement over a single module RSA, in which the adversary has only to 
compromise a single computing xmit. 

Another embodiment of the present invention addresses the situation where the 
adversary is assumed to break into "almost all" of the system, the adversary has access to 
the memory of v < / hardware devices and all t software units. This adversary gets hold 
30 of all software units. It is thus necessary to ensure that the software retained within a 
hardware token suffices for hiding the exponent d. 



- 11 - 




This is an extremely strong adversary and strong assumptions are necessary to 
provide for both efficiency as well as security. It is a plausible assumption that some bits 
of d are known to be hard (hard to guess, as hard as finding d itself) even when the rest of 
the d is known. It is assumed that a jfraction of the low order bits of d are hard. Other 
5 assumptions can be dealt with analogously. 

Assumption: For 0 < e < 1 , revealing log n — (log nf most significant bits does not 
reveal d. (Note: when e is small the upper half of d is easy to compute) 

Strategy / a {rn) that is applied chooses a random number r 
in the range \-h^^ ] where 5 > e, which may force an increase in the size of 

10 domain fi*om which the exponents are drawn. Such increase is always possible with RSA. 
h = log n is the security parameter. 

The protocol can be as efficient as the number of plausible bits which must be 
Q hidden; Smj^ -r can be chosen to minimize the multiplications the hardware token must 

^ perform. For example, a low hamming weight (small number of I's in the string) or a 

15 short string (say, Vi the size of the share). 
m Pseudorandomness is uniformly produced by the devices, for example, using the 

' S same one way function-based on DES with publicly specified keys where its performance 

is message independent. Thus, timing attacks do not apply. Due to the 
Q pseudorandomness, an adversary which looks at the timing of the hardware device and 

20 tries to use the time channel to deduce the permanent share will fail. The reason for such 
failure is the blending of the pseudorandomness, which varies between messages and the 

nr. 

random extraction of each exponents to be done in hardware. This creates a "random key 
schedule" at each execution and thus foils timing attacks. 

Robust Computations with Reduced Communication Using Shared Randomness 

25 Another embodiment of the present invention provides robust computations with 

reduced communication using shared randomness. If a server misbehaves, there may be 
no practicable way to determine who acted incorrectly. Trying all subsets of shareholders 
until a correct signature is computed is too expensive (e.g., when finding a subset of size t 
= //2 +1 of honest parties out of / it would be exponential in /). In these cases Robust 

30 Threshold RSA, in which the combining effort is efficient even when up to / parties are 
adversarial, may be required. Robust Threshold RSA was first introduced in [FGY, 
GJKR]. Namely, Robust Threshold RSA may provide safe assembly which is quickly 
computable and able to verify the information while providing isolation to the shares. 
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In order to verify that an acting server / g A sent a valid partial result, the 
following operation is performed with server /. The shared values added to computations 
presented here will save about half of the communication in the procedure compared with 
that of co-pending application no. 08/842,080 ("Optimal Resilience"). 

5 • (Recall System setup) For each / the system publishes g^' mod n. 

• (User / Setup) Jointly generate shared-value keys a ,j = a /,„a ' ij ... a 'y,,, (for 

fit - • r • • r'y 

1 <j<l) with j and publish commitments g ^ g g\ where g^ g\ 

are of maximal order and discrete log of g\ base g is unknown. 

• For a failed attempt in signing a message m by A: 

10 • Entity / publishes Rij = g^'"'- '-^ (g,) ^^-^^j^'"^ mod n, and 

Ui = UjeA (gi)^'^"'^^^'"^ ^'"'^ where n' (/» = -sign(/ - v) fory ^ v and 1, 
otherwise. 

PRF * (m)L^ pRF / ^ 

• Entity / or J publishes Rij = g (g\) " ^"'^ = (in each pair, only / 
or J need to publish and the other needs to verify). 

15 • A dispute declaration: if there is a dispute between / and y, then they open up 

their commitments to a , ^ and a Ij and one is removed (with an outlook, this 
removal is imtil a refresh for proactivization, as discussed below). 

• Each server J verifies the transition from a poly-share to a simi-share, namely 
that for all / e A\{/}: 

20 = (f^r^riveAfe^vr^'^r ^here V, = FIveA^CO -X.) and 

• If the verification does not pass then a dispute resolution is performed and 
server / is removed and a new A is chosen to perform the signature. 

• Shareholder J publishes Qj= f^^^^(gi) ^^c, /"'^ mod n, 

25 •A proof of knowledge of the discrete log Qj base g\ is performed as described 

in [FGMY2]. (In practice a Fiat-Shamir transferable proof can be sufficient 
based on "ideal bash"). 
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• Use robustness algorithm of [FGY] or [GJKR] (for safe primes), using witness 

• If a shareholder is unable to perform the above, or if it has stopped in the 
middle of the entire protocol, it is eliminated and a new A is used. 

5 This operation is performed to locate cheaters if signing with the sum shares went wrong 
(and with an outlook, as part of the proactive update later). 

This operation is successful in eliminating misbehaving parties. Furthermore, it 
enables in the fault-free case (e.g,, all parties are honest and active in a round), a "non- 
interactive" robustness checking of the "sum shares generation" (when the Fiat-Shamir 
10 method is employed). 

Because of the added efficiency burden, it is recommended that the system be run 
without robustness testing. Only when a proper signature fails for a particular message 
should the robustness enhancements be incorporated to eliminate cheaters. 

Proactive Distributed RSA vnth Shared Randomness 
15 Another embodiment of the present invention involves a proactive distributed 

RSA methodology using shared randomness. A proactive implementation of the 
communication model is discussed in [HJJKY]. The time is divided into time periods 
which are determined by the common global clock (e.g., a day, a week, etc.). Each time 
period consists of a short update phase, during which the servers engage in an interactive 
20 update protocol, at the end of which they hold new shares (in fact, a new sharing) of the 
secret d. After the update, there is a fimction computation phase, in which the servers 
perform the intended secret-key operation using their current sharing of d on numerous 
inputs. 

The adversary is computationally boxmded, and it can corrupt servers at any 
25 moment during a time period by viewing the memories of corrupted servers and/or 
modifying their behavior. One model does not differentiate malicious faults from 
"normal" server failures (e.g.^ crashes). But, when an adversary intruding on a 
shareholder is found it is "removed" (e.g., through a reboot procedure) before the 
shareholder is made operational. The reboot operation is performed immediately when 
30 attacks or deviations from the protocol are detected, and it is overcome during update. 

Within the proactive model, a period for processors to fail by stopping and then 
rejoining (fail-stop and rejoin) may be allowed. Thus, an xmavailable processor is not 
necessarily considered "faulty" in the malicious sense. 
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There are a number of ways shared randomness which is added into algebraic 
computations can help in proactive RSA systems. Full proactive update tokens are 
possible. In addition to share resharing, the pseudorandom functions should be replaced 
by new ones during updates. In fact, when the pseudorandom functions are first updated, 
5 a new shared randonmess mechanism should be obtained, but the function itself should 
remain unchanged. Then interactions are reduced in the update. Change of 
representation "poly-to-sum" and "sum-to-poly" for the system, as described in co- 
pending application 08/842,080, may be performed. (Noting last two steps are not 
needed). The poly-to-sum protocol followed by a sum-to-poly based on renewed shared 
10 randomness, is a secure protocol with reduced interaction compared to the original poly- 
to-sxmi sum-to-poly update. The total number of servers may be changed from / to /', and 
the threshold may be changed fi-om tXo f during an update. 
O Some dynamic updates that are less costly may be employed. One such change is 

5 updating the pseudorandom functions only. This can be done interactively between the 

15 parties, e.g., using Diffie-Hellman with either authenticated key exchange between the 
m parties. 

P Since the parties share randomness, they can also perform what is called a 

^ contingent key exchange based on the Diffie-Hellman key exchange by incorporating 

=;g shared randomness. As an example, let P be a prime, g a generator of large prime order 

^ % 20 of a subgroup of Zp, and A: be a shared random key. Diffie-Hellman key exchange is A 

^3 send mod P and B send g^ mod P and the key is g^^ mod P, which can be computed by 

both A and B. A contingent Diffie-Hellman key exchange incorporates the share 

randomness into the transmissions. That is A and g ^ and B sends 

*+PRF (^'B'\tag^ 

g ^ where tag is an agreed upon nonce. Similarly, it is easy to see that g 

25 can be computed by both A and 5, e.g^B can compute 

a^VRF f;A\tag) FRF f'A^tag) 

(g ^ I g ).As soon as the key is used, e,g, , for encryption, it can 

be determined if both agreed on the same key. 

Proactivization can be used to dynamically add and remove parties (via an 
update). By limiting the operation to adding and removing from the recently updated 
30 group of parties, proactivization can also be accomplished by deciding to employ/not- 

employ the shared randomness shared with the recently updated parties. This is an access 



- 15 - 



# 



control function that computes on keys (analogous to "control vectors" acting on DES 
keys [M]). It assures that limitations on the cooperation can be easily achieved with 
shared randomness (using shared random values as credentials). 

Shared random values can be used for key control, e.g., monitoring which parties 
5 collaborate. This key control can be used to prevent an entity from signing before a 

proactivization step is performed. For example, if an adversary has corrupted a server, it 
is possible to prevent that server from collaborating in a signature before proactivization. 

Whereas fiiU proactive refreshment of cryptographic tools is needed to assure that 
past corruptions (memories learned in the past) are forgotten (namely erased and become 
10 irrelevant), "simpler" mechanisms can be used to assure that future corruptions cannot 
leam the past. This is done by forward refreshment of the keys for shared values. This 
wall ease the simulation argximents as the "pseudorandom past" becomes random. This 
i'3 can be achieved by updating the pseudorandomness based on "current round information" 

and in a non-interactive fashion. A tag (e.g., date or a covmter which can be agreed upon) 
f IJ 15 and previous randomness is used to generate a new pseudorandomness for shared values 

ff~ to add to computations as followed by an update. This can sometimes be extended to a 

^ y full proactive update . 

Using the above technique with [FGMY], fault-free non-interactive (e.g., all 
parties are honest and active in a round) full proactivization is achieved. This is the first 
2 y 20 time that such non-interactive maintenance is possible. It can be derived from [FGMY] 

, Q by sharing pairwise affixments wherein each committee in a family one affixment adds 

and the other affixment subtracts using new locally refreshed pseudorandomness. The 
locally refreshed pseudorandomness is derived from the old key applied to a global tag 
which can be the global public state of this round. The new affixment keys generate new 
25 shares, followed by a non-interactive verification. The following is an example based on 
[F89], in which the secret key d= si+, . St similar to [FGMY]. The new shares now 

become s] = + ^^.^j .^j , sign(? - j) PRF^^^ ^ (^^g)- Before changing the s'i, a signature 

for some tag can be tested with the new shares. For [FGMY] there are many such sets ^i, 
. . . , ^„ (held by a family of servers) such that they sum up to d, and more than one server 
30 can possess Si. 

For robustness of the update, a commitment to a . j is published as before. 

Moreover, the distributor (a single dealer or a distributed one) had published g""' . 
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Publication of commitment to PRF^ .^. {tag) is provided by / using say C, ^ = g '"^ 
Entities / and j may now dispute if they disagree and value is opened if necessary (one 
will be wrong and removed). Each / also publishes g""' for the next round using his share, 
and the following verification is made by each v within a family, with dispute phase if 



5 necessary: g^ =g^ llyeA\{i}l^ 1 ' If dispute, is now used. Asm 

[FGMY2] that / can be converted to /' and t can be converted to f. 

The efficiency gained by applying shared randonmess into computations in 
updates of proactive systems, say, are definitely applicable to the scheme in [R] as well as 
to the scheme of "parallel sum-sharing" of [FGMY], which is very useful in relatively 
10 small scale systems. Other (non-RSA) distributed public-keys can employ this new 
primitive. 

The description herein is exemplary and the notions described can be performed in 
multiple ways. For instance, the shared randomness does not need to be incorporated into 
the exponent, e.g^ V^{tag)g^ and PRF(/ag)g* can be used in the contingent Diffie- 
15 Hellman, as well as during the operational phase of RSA distributed signing (using 

instead partial signature S„^ j j^ ^ (n,eA\[/}^^(jji ^'"^^'^^^ '^^^^ ' mod n. Algebraic 
operations other than addition can be used with shared randomness techniques. For 
instance, if a distributed function is = g^' "'^' mod P by computing 
Vi = iYi,!) ^' where Vq = one could use shared randomness as 

The embodiments described herein are intended to be illustrative and not limiting. 
It will be appreciated that many variations are possible within the scope and spirit of the 
invention. 
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